The most obvious benefit of the digital revolution in the field of multimedia recording has been the clarity and quality of a digital recording, and its resistance to corruption when compared to analog sound recordings. As Internet speed and flexibility advance, digital exchanges of multimedia files such as sound recordings have become common. In the earliest stages of Internet file transfer, large files would typically consume valuable bandwidth, and were time consuming for both the transmitting party and the receiving party. Today, owning to a variety of factors including data compression techniques, digital files, including multimedia files can be transferred over the Internet in formats consuming far less bandwidth. As compression reduces the size of multimedia files, the speed of transmission and processing increases every year. Both these factors contribute to faster and more efficient file exchange over the Internet. At the same time, file storage by end users has also become increasingly practical. Compressed files also consume less space on a hard drive. Additionally, hard drive storage capacity has increased at a staggering rate. As a result, disk drives which were once reserved for storage of essential data, such as a word processing application essential to a business operation, have increasingly supported storage of recreational data, from games to multimedia data files such as MP3 audio and MPEG-2 video. The confluence of these advances has created a widening market of file sharing across the Internet. In a typical Internet file transfer, files are first compressed and then transmitted over the Internet. Some files are decompressed when re-stored at their new location. As microprocessors speeds have increased, however, it is often possible to decompress a file while it is actually running. This is particularly true for audio MP3 files, and will probably become more true for MPEG video files as processing speeds continue to increase. Originally, file sharing over the Internet was largely “point to point,” such as occurs when a first person sending a file to a second person and “centralized file sharing” such as downloading new virus patterns or a new driver from a central location, such as a merchant web site. Recently, however, de-centralized file exchanges have become popular through the application of central index servers. In a de-centralized network, clients log on to a central index server, and files available for sharing within each of the clients are logged into the central index server, along with an IP address or other identity of the client computer containing the files available for sharing. The clients are then able to share or swap any files among themselves that are listed in the index server, thereby directing each client to another client or clients where a particular file may be located. Clients are thus able to share files with other clients when they might otherwise have never known of the existence of such an available file.
To maintain a “fluid” or substantially real time network, when a client initially logs onto the index server, the index server searches certain file locations within the memory of the client and generates a log relating specific data or program files found at that location. This log is indexed against the internet protocol (IP) addresses of that respective client. Similarly, when a client logs off, a disconnect signal initiated by the client, or a periodic “ping” initiated by the server to determine if the client is still on-line, allows the central index server to update the index and purge file identifications referenced to a client that is no longer on line. In this manner, the central index server is capable of maintaining a substantially real-time index of clients on line, and a corollary real time index of the data files respectively stored in the clients that are on line at any given time. Because the central index server is able to maintain a substantially real time index in a decentralized network wherein clients are expected to be continually logging on and off, the network is said to be “fluid.” The continual logging on and logging off by clients does not substantially degrade the reliability of the data indexed within the main data base of the central index server in a fluid network.
If more than one on-line client has the same data or program file, that data or program file is logged multiple time in association with the multiple client possessors. A requestor client seeking that particular file can then be directed to any other clients who are shown in the index server to possess the requested file. The index server also facilitates connection between a requester and a provider when a client requesting a particular file is matched to a particular provider in possession of the requested file. In this way, each client can be both a requester and a provider while logged onto the index server. The network is “distributed” or “de-centralized” in that the files are not located in the central server . . . only an index identifying the available files and their various IP addresses is stored within the central index server. The files themselves are located at diverse locations in client computers distributed across the network. Background for methods and apparatus for file swapping over a fluid, de-centralized network through a central index server is found in U.S. patent application Ser. No. 09/464,653, Real Time Search Engine to Fanning et al., filed Dec. 15, 1999, and U.S. patent application Ser. No. 09/560,106, Use Sensitive Distribution of Data Files Between Users to Fanning et al., filed Apr. 28, 2000.
FIG. 1 is a simplified depiction of a decentralized network configured for file sharing through a central index server. Client A and Client B have both logged onto the central index server 101 through the server interface 107. Within the central index server 101 is a main data base 102. Client A 103 possesses The Beatles “A Hard Day's Night,” “Help,” and “Yesterday” within its memory, and is seeking a copy of Max Bruch's Violin Concerto #1. Client B 105 has also logged onto the index server. Client B 105 currently has Gustav Holtz “The Planets,” Brahms' “Academic Festival” and the Bruch Violin Concerto #1 stored in memory, and is seeking a copy of Gershwin's “Rhapsody in Blue.” Because the index server 101 has surveyed each client 103, 105 as those clients logged on, the server 101 has indexed within its main data base 102 a log of all data files stored in the various client computers 103, 105 which are presently on line. Unlike the clients computers 103, 105, however, which possess an entire data file, the indexed entries 110, 112, 114, 116 within the index server 101 only contains an identifier of the file, such as the song title, which is indexed against the IP address of the client possessing the actual file. According to the example depicted in FIG. 1, the index server will provide Client A 103 an address of at least one client currently on line who possess a file of Max Bruch's Violin Concerto #1 in memory. Typically the index server will provide a list of multiple clients from whom the desired file might be obtained, and the client seeking the data file will examine a variety of data to determine from which of the potential sources the desired file might be obtained most efficiently and reliably. When the requesting client decides upon a specific provider client, communication is established between the two clients, and the file is transferred.
FIG. 2 illustrates representative data fields which may be stored within each client computer in conjunction with a sound recording. The fields typically include song title 201, composer 202, lyricist 203, performing artist 204, group or band 205, album title 206, MD5 identifier 207 bit rate 208 and frequency 209. The function of an MD5 identifier 207, bit rate 208 and frequency 209 will be discussed below. The two brackets 211, 213 differentiate groups of this data which are used for different purposes. The first bracket 211 represents a song certificate, and comprises data identifying the sound recording stored in the client computer. When the client computer 103 logs onto the central index server 101 and the central index server indexes a sound recording against the IP address of a client computer 103, the index within the central index server typically comprise the song certificate data 211 of FIG. 2, potentially excluding some of the fields listed, or including similar fields not shown.
The second bracket 213 represents a file certificate. A file certificate 213 includes data essential to re-play the sound recording stored in the data file. As discussed explained herein, the de-compression of an MP3 file requires data about how the recording was “ripped” including bit rate 208 and frequency rate 209. Since the entire sound recording file is not stored in the central server index 101, is not played by or within the central server index 101, and is, upon facilitation by the central server index, transferred directly from a first client computer 103 to a second client computer 105, the file certificate data, much of the data within the file certificate 213 is not typically stored within the data base of the central index server 101.
The explosive growth and popularity of de-centralized file swapping of multimedia data files such as sound recordings through the intermediary assistance of index servers has created a derivative concern with respect to the possible violation of copyright protected works which could theoretically be exchanged through such a process. Because the central server does not contain data files, but only indexes the data files stored in the client memories currently logged on, protected works within the memory of one client could theoretically be requested by a requesting client, and transferred from a provider client. Without copyright safeguards, the central index server 101 will blithely connect the requester client 103 to the provider client 105, unwittingly facilitating a copyright infringement between the two client computers 103, 105.
Early efforts to restrict file sharing or swapping of restricted files were limited to flagging the names of copy-restricted files within the memory of the index server. If a request for a copy-restricted file were entered, the central index would refuse to facilitate a connection between a requestor client and a provider client. Such a security system, however, proved easy for increasingly sophisticated consumers to hack or circumvent. File copying and sharing restrictions could be evaded by simply re-naming a file. For exemplary purposes only, assume that the Beatles' songs “Help” and “Yesterday” are copy restricted. By publicized announcement among network hackers, potential users would be notified that everyone was to re-name and/or request data files according to a common algorithm, such as appending an “X” as the last letter of all song titles such that “Help” is renamed “Helpx” and “Yesterday” as “Yesterdayx.” Through such machinations, users could thwart basic copyright protection programs within the central index server. A security system configured to prohibit file sharing of specific titles such as “Help” and “Yesterday” might not be programmed or equipped to prevent the exchange of files entitled “Helpx” or “Yesterdayx.”.
There exists therefore a need for a method and apparatus for controlling file distribution of multimedia files over a de-centralized network which is coordinated through an intermediary central index server. There further exists a need for identifying copyright protected works in a central index server in order to control the distribution of copyright protected material over a de-centralized network. There is also a need for a tamper resistant method and apparatus for restricting network sharing of copy restricted files, thereby frustrating attempts by hackers to breach security measures within a central index server designed to prevent the sharing of copyrighted material. There is a further need for a hacker-resistant system that can be implemented efficiently, thereby minimizing delays associated with the implementation of tamper resistant security measures. There is further a need for a security system for preventing file sharing of copy restricted information that does not incur an unreasonable delay in the file identification process during a single file sharing session of limited duration.